Increasing advances in computer technology (e.g., microprocessor speed, memory capacity, data transfer bandwidth, software functionality, and the like) have generally contributed to increased computer application in various industries. Ever more powerful server systems, which are often configured as an array of servers, are often provided to service requests originating from external sources such as the World Wide Web, for example. As local Intranet systems have become more sophisticated thereby requiring servicing of larger network loads and related applications, internal system demands have grown accordingly as well. As such, much business data is stored in databases, under the management of a database management system (DBMS).
Typically, such databases can be viewed as organized collection of related information stored as “records” having “fields” of information therein. As an example, a database of finances may have a record for financial transactions such as accounts receivables, amount owed, customer information and the like. Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, the database management system or DBMS is typically provided as a software cushion or layer. As such, the DBMS can shield users of the database from concerns about the underlying hardware-level details. Generally, all requests from users for access to the data are processed by the DBMS. For example, information can be added or removed from data files, information retrieved from or updated in such files, and the like, all without user knowledge of underlying system implementation. Thus, the DBMS provides users with a conceptual view of the database that is removed from the hardware level itself.
While interacting with such computer systems, many applications employ a function referred to as locking to ensure that data the applications are modifying is not modified by another application or process. Typically, such locking of the data can prevent users from changing the same data at the same time. If such locking mechanisms do not operate properly, data can become logically incorrect, and future use of the data can produce unexpected results. In addition, multiple transactions trying to use the same data concurrently can give rise to several different types of problems referred to as concurrency problems.
Such problems can cause updates of data by one application to be lost or overwritten by another application. Sometimes data is modified, but not immediately written out in a manner that it can be read by other applications. This can also result in reads of data which should be the same, not being the same. Further problems can result from applications using copies of data, which are then changed by a later application. While there are several different types of locks, such as exclusive locks, shared locks, update locks and other types of locks, many of them provide some amount of concurrency to ensure that two applications do not modify data at the same time, or use data which may or may not be accurate. Such types of locks can consume system resources and have associated costs. Fine grain locks, which lock on a small amount of data, such as on a row of a database, each have memory resources and processing resources associated with storing and managing them. If many rows are involved in a transaction which needs to lock portions of the database to ensure concurrency, a significant amount of system resources can be consumed. The problems associated with the lock control can include a trade off between the transaction concurrence based on the granularity of the locked data unit and the overhead in the lock control processing.
Moreover, for such systems over-locking can create problems, wherein a transaction acquires more locks than is necessary and/or holds locks for longer than is required. Typically, while such over-locking will not necessarily result in transaction isolation being violated, it can lead to a reduction in the concurrency that the system can support. Put differently, resources can be locked that need not be locked, thus becoming unavailable to other transactions.
At the same time, minimizing the locks that are retained during a transaction's operation can pose problems when a lock hierarchy is involved. For example, placing an X lock on a row will typically result in IX locks being placed on all parent objects of the row, e.g., page, table and database.
In such cases, even if the row lock is simply discarded prior to the completion of the transaction, discarding associated parent resources or locks can be a challenging task. Furthermore, even if such associated parent locks are identified and removed, they still may need to be reacquired immediately for subsequent operations, hence creating an inefficient procedure
Therefore, there is a need to overcome the aforementioned deficiencies associated with conventional systems and methodologies related to database operations.